Draft: draft-ietf-taps-interface

Commentary: This addresses Issue 
 So , some comments : First I suggest that we explicitly refer to these but the service they provide , not the protocol they resemble . Hence : • The final one would be " datagram service " and UDP is an example of such . • I would also suggest it is useful to say that the application - supplied properties can now override these defaults , hence in the Datagram case , the property permitting / requiring partial coverage could result in UDP - Lite being selected instead of UDP to supply this service . • Then , I have a question about the specific UDP / Datagram service . This currently says : To me some of these are not really requirements , but to me seem like side affects . The requirement could be to need low latency , and idempotence , preserve - msg - boundaries , etc but I would n't care if the service also happened to provide the following , as long as those requirements ( or whatever we agree upon ) were prioritised : reliability , preserve - order , congestion - control . ( Of course UDP would not offer these , and that would also be fine ) . Thoughts ? 
 I agree with the first point and updated the PR accordingly . For the second one , I also agree that avoiding reliability , order preservation , and congestion - control are side effects of latency or other optimisations and do not really belong into the profile . Therefore , I changed " avoid " to " ignore " . I am a bit hesitant about speaking about UDP lite here given your first point , tried to incorporate it as a hint in a slightly different way . After these changes , I would like to raise the question whether we should mention " udp like " or " tcp like " for the impatient searching the document . 
 Something to help start thinking : we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport ? 
 Something to help start thinking : we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport ? 
 I checked this now and like it . I also read the dialogue and agree with all points that were raised and how they were answered . Regarding 's suggestion to say : " we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport ? " - actually , when reading the update first before looking at the comments , I thought " why does n't this say : ' an example of a protocol that provides this service is UDP ' ? " . I think this is almost the same thing , but I like my own phrasing better :) the whole " socket API that binds to " thing seems a bit clumsy to me and I do n't think we need it . 
 I liked the split between saying " there are profiles " in the normative part and defining examples for these in the appendix . If this is a Problem , we should rather move the profiles into the property section . I have a bad feeling about modifying function signatures defined in the main documents in the appendix . Any other opinions ? Leave un - merged and discuss in Montreal ? 
 I actually think this is useful but more an implementation question . I do n't think this need to a part of the base API , so having this in the appendix or the implementation draft seems more suitable for me . 
 What about the Parameter to pass the profile – is re - defining it in the appendix the right way ? 
 The API we define is anyway mostly a recommendation and will not be normative ; so you will always she slight variations in the implementation . Proposing an optional parameter ( in the appendix or implementation draft ) seems okay . 
 This issue was discussed in the May 2019 interim . After fist implementation experiences , we feel that we should add a convenient way to express common Transport Parameter combinations as some kind of profile , e.g. " TCP like " meaning " Reliable , in - order , non - message preserving " 
  how to solve this : Replace the TransportProperties constructor in section 5.2 with promised this at the interim . I only open this issue to document the proposal how to solve this . 
 This can be closed . 
 Thanks , this is useful ! However , I think it would be better self - contained in the appendix .
Paragraph (version B):
As preference typed selection properties may be used quite
frequently, implementations should provide additional convenience
functions as outlined in preference-conv.  In addition,
implementations should provide a mechanism to create
TransportProperties objects that are preconfigured for common use
cases as outlined in property-profiles.
Paragraph (version B):
This property specifies whether an application would like to supply a
Message to the transport protocol before Connection establishment,
which will then be reliably transferred to the other side before or
during Connection establishment, potentially multiple times (i.e.,
multiple copies of the message data may be passed to the Remote
Endpoint).  See also msg-idempotent.  The recommended default is to
Ignore this option.  Note that disabling this property has no effect
for protocols that are not connection-oriented and do not protect
against duplicated messages, e.g., UDP.
Paragraph (version B):
This property specifies that the application would prefer multiple
Connections within a Connection Group to be provided by streams of a
single underlying transport connection where possible.  The
recommended default is to Prefer this option.
Paragraph (version B):
This property specifies whether the application desires protection
against corruption for all data transmitted on this Connection.
Disabling this property may enable to control checksum coverage later
(see msg-checksum).  The recommended default is to Require this
option.
Paragraph (version B):
This property specifies whether the application desires protection
against corruption for all data received on this Connection.  The
recommended default is to Require this option.
Paragraph (version B):
where messageData is the data object to send.
Paragraph (version B):
The optional endOfMessage parameter supports partial sending and is
described in send-partial.
Paragraph (version B):
Note that message properties are per-Message, not per-Send if partial
Messages are sent (send-partial).  All data blocks associated with a
single Message share properties specified in the Message Contexts.
For example, it would not make sense to have the beginning of a
Message expire, but allow the end of a Message to still be sent.
Paragraph (version B):
A Received event indicates the delivery of a complete Message.  It
contains two objects, the received bytes as messageData, and the
metadata and properties of the received Message as messageContext.
Paragraph (version B):
Delimiter-separated formats, such as HTTP/1.1.
Paragraph (version B):
This property specifies which scheduler should be used among
Connections within a Connection Group, see groups.  The set of
schedulers can be taken from RFC8260.