Draft: draft-ietf-taps-interface

Commentary: This is my attempt to address items 2 , 3 and 4 . My suggestion is not to do anything about item 1 ( referencing -arch ) , because we already do this so often and IMO it wo n't improve the document to add yet another reference . See also the discussion in . 
 These are some minor comments ( mostly editorial ) /nits , that would be best to address before going for IETF Last call but can be taken care during or after the IETF LC . Section 3 should reference architecture document . We are using concepts and definitions from the architecture document and lets be specific about it . Of we can mention this in the terminology section . Section 8.1.1 : the description of Full Coverage is given in section 9.1.3.6 . Either forward ref that section where it is explained or move the text in section 8.1.1 . Section 8.1.6 : says - When the capacity profile is set to a value other than Default , z Transport Services system SHOULD select paths and configure protocols to optimize the tradeoff between delay , delay variation , and efficient use of the available capacity based on the capacity profile specified . here " z " ? ? Section 9.1.3.1 : says - The  specifies how long a particular Message can wait to be sent to the Remote Endpoint before it is irrelevant and no longer needs to be ( re-)transmitted . can we describe whether this wait till the Message is sent out of the TAPS system or will the wire ( which might include other processing delay by the system ) ? 
 Regarding the first item : I think this is overkill . Section 1 begins with : " This document specifies an abstract application programming interface ( API ) that specifies the interface component of the high - level Transport Services architecture defined in [ I - D.ietf - taps - arch ] . " Section 2 begins with " The design of the API specified in this document is based on a set of principles , themselves an elaboration on the architectural design principles defined in [ I - D.ietf - taps - arch ] . " - adding something like this to section 3 or section 1.1 too is not making anything clearer , IMO . 
 The problem I see is that in section 3 we are describing the Connection and Preconnection again . Note that I am using the word " describing " as those are already defined and described in the  doc we just need to ref them or say see there in the Interface doc . I would like to avoid the situation that readers are confused and any future update to the Interface doc is problematic to decide which definition / description to preserve . I think just adding a sentence in the terminology section saying things are defined in  document make sense . But hej , this is a minor comment so ...
Paragraph (version A):
If this property is an Integer, it specifies the minimum number of
bytes in a received message that need to be covered by a checksum.  A
receiving endpoint will not forward messages that have less coverage
to the application.  The application is responsible for handling any
corruption within the non-protected part of the message RFC8085.  A
special value of 0 means that a received packet may also have a zero
checksum field.
Paragraph (version B):
If this property is an Integer, it specifies the minimum number of
bytes in a received message that need to be covered by a checksum.  A
receiving endpoint will not forward messages that have less coverage
to the application.  The application is responsible for handling any
corruption within the non-protected part of the message RFC8085.  A
special value of 0 means that a received packet may also have a zero
checksum field, and the enumerated value "Full Coverage" means that
the entire Message needs to be protected by a checksum.
Paragraph (version A):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, z Transport Services system SHOULD select paths and
configure protocols to optimize the tradeoff between delay, delay
variation, and efficient use of the available capacity based on the
capacity profile specified.  How this is realized is implementation-
specific.  The Capacity Profile MAY also be used to set markings on
the wire for Protocol Stacks supporting this.  Recommendations for
use with DSCP are provided below for each profile; note that when a
Connection is multiplexed, the guidelines in Section 6 of RFC7657
apply.
Paragraph (version B):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, the Transport Services system SHOULD select paths and
configure protocols to optimize the tradeoff between delay, delay
variation, and efficient use of the available capacity based on the
capacity profile specified.  How this is realized is implementation-
specific.  The Capacity Profile MAY also be used to set markings on
the wire for Protocol Stacks supporting this.  Recommendations for
use with DSCP are provided below for each profile; note that when a
Connection is multiplexed, the guidelines in Section 6 of RFC7657
apply.
Paragraph (version A):
The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted.  This is a hint to the Transport
Services implementation - it is not guaranteed that a Message will
not be sent when its Lifetime has expired.
Paragraph (version B):
The Lifetime specifies how long a particular Message can wait in the
Transport Services system before it is sent to the Remote Endpoint.
After this time, it is irrelevant and no longer needs to be
(re-)transmitted.  This is a hint to the Transport Services
implementation - it is not guaranteed that a Message will not be sent
when its Lifetime has expired.