Draft: draft-ietf-taps-impl

Commentary: Section 5.1.2 : " the implementation should hold off on processing Messages until the batch is complete " assumes that there is indeed a context - switch penalty .  semantics are only for hints to the implementation / protocol stack , and this advice only applies when that hint allows the stack to reduce context switch penalty . Correct ? ( If so , this should be noted explicitly ) 
 Actually 5.1.3 . This reads odd to me , I 'd expected myself more like : " When this is used , the implementation can defer the processing Messages until the batch is complete . " ( eliminating " off on " , also from this sentence ? ) 
 Agreed , I think your text reads better should it be " ... defer the processing of Messages ... " though ? I think it also solves the question from as it is now expressed as an opportunity for the implementation . 
 I believe these are all editorial . First , this list needs some front matter : " protocols should implement each of the following Message Properties on send as follows " or similar . " Ordered " should state that protocols that do not support configurable ordering may ignore the property . " Final " should note that it is not mandatory to close the connection after a Final message . " Corruption Protection Length " should note that it can be ignored basically everywhere but UDP - Lite . One open question : is it an error to send a Message after a Final message , and does the protocol implementation need to handle this itself ? 
 ... " Corruption Protection Length " should note that it can be ignored basically everywhere but UDP - Lite . ... In protocols such as UDP - Lite , various tunnels would , DCCP allows , etc . 
 I think it should be an error to send a Message after a Final message and the implementation of the transport services system should handle it . If it is not an error , then it will fail sometimes and sometimes not depending on if the connection is closed or not , that seems less useful to me .
Paragraph (version A):
Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering.
Paragraph (version B):
Ordered: when this is false, this disables the requirement of in-
order-delivery for protocols that support configurable ordering.
When the protocol stack does not support configurable ordering,
this property may be ignored.
Paragraph (version A):
Final: when this is true, this means that a transport connection
can be closed immediately after transmission of the message.
Paragraph (version A):
Corruption Protection Length: when this is set to any value other
than "Full Coverage", it sets the minimum protection in protocols
that allow limiting the checksum length (e.g.  UDP-Lite).
Paragraph (version B):
Final: when this is true, this means that the sender will not send
any further messages.  The Connection need not be closed (in case
the Protocol Stack supports half-close operation, like TCP).  Any
messages sent after a Final message will result in a SendError.
Paragraph (version B):
Corruption Protection Length: when this is set to any value other
than "Full Coverage", it sets the minimum protection in protocols
that allow limiting the checksum length (e.g.  UDP-Lite).  If the
protocol stack does not support checksum length limitation, this
property may be ignored.
Paragraph (version A):
Since sending a Message may involve a context switch between the
application and the transport system, sending patterns that involve
multiple small Messages can incur high overhead if each needs to be
enqueued separately.  To avoid this, the application can indicate a
batch of Send actions through the API.  When this is used, the
implementation should hold off on processing Messages until the batch
is complete.
Paragraph (version B):
Since sending a Message may involve a context switch between the
application and the transport system, sending patterns that involve
multiple small Messages can incur high overhead if each needs to be
enqueued separately.  To avoid this, the application can indicate a
batch of Send actions through the API.  When this is used, the
implementation can defer the processing of Messages until the batch
is complete.