Draft: draft-ietf-taps-interface

Commentary: Btw why do we have ( only ) properties for the TCP UTO ? 
 I did n't get that this is only an example , so yes we should say this more explicitly . Not sure where to put that though . Maybe we can just merge this PR for now and have a separate PR to add this somewhere . 
 I actually also just " as an example for a protocol - specific property " in that section but maybe we want to say it somewhere else again ... ? 
 It is n't just an example . The reasons it 's there go back to minset ( if you remove it , you lose this functionality forever ) , yet there were arguments for this being a special TCP thing only , and being too awkward to include as general functionality - much like there are now arguments that might lead to ECN becoming UDP - specific . 
 Some more explanations : why is this included ? From appendix C , we can see that it relates to " Suggest timeout to the peer " in minset . The argument for including this , in appendix A of the minset draft , is : " Functional because this is closely related to potentially assumed reliable data delivery . " Indeed , the last paragraph of section 1 in RFC 5482 gives examples where communication might just fail for applications expecting their connections to stay up . in reality , this does n't seem to be needed much , and so this is hardly implemented ( if at all!).why is it TCP specific ? This was discussed in issue : The key statement against having this as a general thing is probably this sentence from " If we had a timeout on overall connection establishment , from Initiate ( ) to Ready ( ) , then that 's trying to set a timeout not just on TCP , but on DNS , racing , proxies , TLS , and who knows what else . " 
 Okay , let 's merge this and then think about how to motivate that we specify UTO . If we do it because it 's in minset , that means that implementations have to expose UTO to be TAPS - compliant because TAPS requires that implementations at least expose the features in minset . Also , I think we should say is that there 's more Protocol - Specific Properties and we do n't specify all of them here , but implementations are free to add their own .
Paragraph (version A):
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.
Paragraph (version A):
a boolean (default false) to control whether the UTO option is
enabled for a connection.  This applies to both sending and
receiving.
Paragraph (version A):
a boolean (default true) which controls whether the "Timeout for
aborting Connection" (see conn-timeout) may be changed based on a
UTO option received from the remote peer.  This boolean becomes
false when "Timeout for aborting Connection" (see conn-timeout) is
used.
Paragraph (version A):
All of the above parameters are optional (e.g., it is possible to
specify "User Timeout Enabled" as true, but not specify an Advertised
User Timeout value; in this case, the TCP default will be used).
Paragraph (version B):
These properties specifies configurations for the User Timeout Option
(UTO), in case TCP becomes the chosen transport protocol.
Implementation is optional and of course only sensible if TCP is
implemented in the transport system.
Paragraph (version B):
All of the below parameters are optional (e.g., it is possible to
specify "User Timeout Enabled" as true, but not specify an Advertised
User Timeout value; in this case, the TCP default will be used).
Paragraph (version B):
This time value is advertised via the TCP User Timeout Option (UTO)
RFC5482 at the remote endpoint to adapt its own "Timeout for aborting
Connection" (see conn-timeout) value accordingly.
Paragraph (version B):
This property controls whether the UTO option is enabled for a
connection.  This applies to both sending and receiving.
Paragraph (version B):
This property controls whether the "Timeout for aborting Connection"
(see conn-timeout) may be changed based on a UTO option received from
the remote peer.  This boolean becomes false when "Timeout for
aborting Connection" (see conn-timeout) is used.