Draft: draft-ietf-taps-interface

Commentary: ... and some nits ( capitalization , .. ) : 0 - rtt establishment : fixed default as requested by and incorporated text fix suggestion : last missing update to hopefully close this issue : adjusted the wording of checksum related selection properties : fixed some text details regarding how transport properties are to be specified , based on a converged discussion . : wrote some defaults for parameters in section 9.1 
 With the exception of read - only Properties , something should be said about the default values of the Generic Connection Properties in Section 9.1 . 
 fixed by 
 Section 4.2.1 : “ Allow different components of a TAPS implementation to pass Transport Properties , e.g. , between a language frontend and a policy manager . ” Question ? ? ? : Would it also be OK to include a suggestion that these could also be retrieved from storage , e.g. “ Allow different components of a TAPS implementation to pass Transport Properties , e.g. , between a language frontend and a policy manager , or to retrieve a list of properties from a file or other storage . ” Section 4.2.1 . : Are the definitions of “ should ” actually “ SHOULD ” , I do n’t otherwise understand the meaning of the lower case should . Actually , why is it SHOULD not MUST for the IETF - specified class ? 
 I am in favour of adding the suggestion for using this representation on stable storage , but should n't it be rather " or as a representation of properties retrieved from a file or other storage . " I chose " should " over " must " here because I feared defining protocol specific properties for all important IETF protocols may creep in as a dependency for publication of this document otherwise . With regarded to the casing , this really must be a SHOULD . 
 fixed by 
 In Section 5.2.7 Control checksum coverage on sending “ The recommended default is to  this option . ” I argue that this default is much braver than specified in the IETF present in RFC 8085 . The default for IPv6 is also that this is required by default . Again , I would argue that applications need to explicitly be designed to accept this . — In Section , 5.2.8 . Control checksum coverage on receiving “ The recommended default is to  this option . ” I argue that this default is much braver than specified in the IETF present in RFC 8085 . The default for IPv6 is also that this is required by default . Again , I would argue that applications need to explicitly be designed to accept this . 
 this seems reasonable to me , I do n't recall how we ended up at  . 
 I think we need to re - phrase this as I guess you mis - read it . The property only defines whether you want a protocol that provides this feature , not whether it should be enabled . The latter is controlled by the property in 7.3.6 . 
 Yes , this seems to be a misunderstanding . Perhaps we also need to clarify that  just means that the property is ignored when ranking alternatives for candiadet selection and racing , not that the application can ignore it ? 
 I do n't understand something about 5.2.7 and 5.2.8 ... So let me ask a more stupid question : IETF transports always do provide full coverage by default . Why do we have a property to request control of checksum coverage at all , why do n't we just have a property that says you want to have ( require ) or would like to have ( prefer ) , or do n't care ( ignore ) some size of limited checksum coverage - as in 7.3.6 . If you do n't get the coverage that you ask for , then you will get more coverage . ... so " require " is in some way " prefer a protocol that gives at least an ability to provide this much ? " . Then in 7.3.6 : I think " This property specifies the length of the section of the Message .... " is actually the minimum length of message - the transport can always protect more . I do n't understand : " ... a special value ( e.g. -1 ) can be used to indicate the default . " the default is full coverage , how is this different to a zero parameter ?    TAPS interim , let 's Avoid this . 
 PR partially addresses this : 6 was re - written to include " minimum " and fix the special value related text , also using the same style as in the other Message Properties now to specify the default . 
 PR addresses the last missing bit here : I changed both Selection Properties to ask for full coverage and have them default to Require . The effect is similar to before , but intuitively this is clearer and makes more sense , I suppose . 
 fixed by 
 In Section 5.2.5 : Use 0 - RTT session establishment with an idempotent Message “ The recommended default is to Prefer this option . ” I argue that this default is much braver than specified in the IETF present . Once could argue the same for QUIC , but the TCP - basis for this feature was determined , based - as I recall - on the need for idempotent data and the need to provide server - side support that was not specified . The safe option is to not enable this as a default , requiring  to explicitly say their data is idempotent . “ potentially multiple times ” - probably should be explicitly explained that “ the transport does not provide idempotency , which could result in multiple copies of the message data being passed to the Receiving Endpoint . ” 
 And ... This was relating to TCP , SCTP , etc - which are connection - oreinted . We maybe should discuss this with respect to the Datagram case ( UDP et al ) in issue . 
 LGTM , modulo suggested nit about integers .
Paragraph (version A):
Allow different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a
policy manager.
Paragraph (version B):
Allow different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a
policy manager, or as a representation of properties retrieved
from a file or other storage.
Paragraph (version A):
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.  See
also msg-idempotent.  The recommended default is to Prefer this
option.
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 A):
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 have this option.
Paragraph (version A):
This property specifies whether the application considers it useful
to enable, disable, or configure a checksum when sending a Message.
The recommended default is to Ignore this option.
Paragraph (version A):
This property specifies whether the application considers it useful
configure whether to require a checksum or not when receiving.  The
recommended default is to Ignore this option.
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 A):
This property specifies after how many retransmissions to inform the
application about "Excessive Retransmissions".
Paragraph (version B):
This property specifies after how many retransmissions to inform the
application about "Excessive Retransmissions".  The special value -1
means that this notification is disabled.
Paragraph (version A):
This property specifies the part of the received data that needs to
be covered by a checksum.  It is given in Bytes.  A value of 0 means
that no checksum is required, and a special value (e.g., -1)
indicates full checksum coverage.
Paragraph (version B):
This property specifies the part of the received data that needs to
be covered by a checksum.  It is given in Bytes.  A value of 0 means
that no checksum is required, and the special value -1 indicates full
checksum coverage.
Paragraph (version A):
This property specifies how long to wait before deciding that a
Connection has failed when trying to reliably deliver data to the
destination.  Adjusting this Property will only take effect when the
underlying stack supports reliability.
Paragraph (version B):
This property specifies how long to wait before deciding that a
Connection has failed when trying to reliably deliver data to the
destination.  Adjusting this Property will only take effect when the
underlying stack supports reliability.  The special value -1 means
that this timeout is not scheduled to happen.
Paragraph (version A):
This property specifies which scheduler should be used among
Connections within a Connection Group, see groups.  The set of
schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata.
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.
Paragraph (version A):
This property specifies an upper-bound rate that a transfer is not
expected to exceed (even if flow control and congestion control allow
higher rates), and/or a lower-bound rate below which the application
does not deem a data transfer useful.  It is given in bits per
second.
Paragraph (version B):
This property specifies an upper-bound rate that a transfer is not
expected to exceed (even if flow control and congestion control allow
higher rates), and/or a lower-bound rate below which the application
does not deem a data transfer useful.  It is given in bits per
second.  The special value -1 indicates that no bound is specified.
Paragraph (version B):
a time value (default: the TCP default) to be advertised via the
User Timeout Option (UTO) for the TCP at the remote endpoint to
adapt its own "Timeout for aborting Connection" (see conn-timeout)
value accordingly.