Draft: draft-ietf-taps-interface

Commentary: This does the following things with the properties from the appendix , based on direction of communication : moved to the main text " Suggest a timeout to the Remote Endpoint " : moved to the main text but explicitly described as a TCP - specific property ; also changed it to contain all the parameters that UTO really has traffic category : removed .  said " Let 's see if there 's anything in the implementation document that actually needs this information " but I figured that chances are low , and if this really happens we can still re - introduce this later . size to be sent or received : removed duration : removed send or receive bit - rate : changed this to specify an upper and/or lower bound cost preferences : kept in the appendix , but inserted mirja 's comment " Not convinced cost preferences are on the right level . " ( what did you mean with " on the right level " ? ) 
 Cost does n't seem to mean too much for the transport layer . I guess it could e.g. make more sense to specified which link technology you prefer ( e.g. wifi over cellular ) ( which would be on a less abstract level ) . However , still not sure what the right level is ... 
 I 'm not so keen on specifying link technology - a transport only knows the local link - and that can be very different to the technology of the path bottleneck . Maybe cost is n't that bad - sometimes the presence of cost IS known , or at least a decision could try to be made to minimise cost . It 's hard to do more than hint at this . 
 Thinking about cost prefernce a bit further and with respect to comment that this could part of an layer on top of taps , I would prefer to not include it expect we have some concrete implementation example guidance in the implementation draft . 
 that all sounds very reasonable to me , thanks for clarifying ! So it seems fit where the cost preferences are now in this PR - I left them in the appendix for now , with a mark saying that we 'll see if there will suitable text in the implementation draft . 
 Thanks for doing this ! I have just two suggestions about what section to place the properties in . About the Cost Preferences discussion , I think having both this and the less abstract interface preference in there makes sense , and then the implementation can map those properties to each other . The alternative would be to make this part of the " layer on top of the TAPS API " , which some of the other Intents would end up on as well . If we do this , I think it might make sense to keep the other Intents in the appendix for now ( instead of deleting them like this PR does).lgtm !
Paragraph (version B):
a boolean (default false) to control whether the UTO option is
enabled for a connection.  This applies to both sending and
receiving.
Paragraph (version B):
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 B):
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).