Change:
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 won'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 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. 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 Arch 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 Arch document make sense. But hej, this is a minor comment so...

Discussion:
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 <del> checksum field. </del> <ins> checksum field, and the enumerated value "Full Coverage" means that the entire Message needs to be protected by a checksum. </ins> 8.1.2.

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 <del> Default, z Transport Services system SHOULD select paths and </del> <ins> Default, the Transport Services system SHOULD select paths and </ins> 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-

infinite <del> 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. </del> <ins> 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. </ins> Setting a Message's Lifetime to infinite indicates that the application does not wish to apply a time constraint on the