Change:
does not deem a data transfer useful.  It is given in bits per second.  The special value -1 indicates that no bound is specified. <del> 10.1.12. </del> <ins> 10.2. </ins> <del> This property specifies, for the case TCP becomes the chosen transport protocol: </del> <ins> 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. </ins> <del> 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. </del> <ins> 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). </ins> <del> a boolean (default false) to control whether the UTO option is enabled for a connection.  This applies to both sending and receiving. </del> <ins> 10.2.1. </ins> <del> 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. </del> <ins> tcp.user-timeout-value </ins> <del> 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). </del> <ins> Integer </ins> <del> 10.2. </del> <ins> Default: :the TCP default 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. 10.2.2. tcp.user-timeout Boolean false This property controls whether the UTO option is enabled for a connection.  This applies to both sending and receiving. 10.2.3. tcp.user-timeout-recv Boolean true 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. 10.3. </ins> Asynchronous introspection is also possible, via the SoftError Event. This event informs the application about the receipt of an ICMP error

Discussion:
Btw why do we have (only) properties for the TCP UTO?
I didn'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 added "as an example for a protocol-specific property" in that section but maybe we want to say it somewhere else again...?
It isn'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 doesn'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 : URL The key statement against having this as a general thing is probably this sentence from NAME "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 don't specify all of them here, but implementations are free to add their own.