Summary: Has enough positions to pass.
I agree with Warren that a table for section 3 would be useful and with Mirja that draft-ietf-taps-transports-usage-udp should have been a part of this document.
Substantive: - General: There's a smattering of 2119 keywords in this draft. Other than when used in direct quotes,I assume they describe pre-existing requirements. If so, then please use descriptive language without 2119 keywords. (Otherwise, see Ekr's comment.) -8, first paragraph: Doesn't QUIC provide those features "on its own"? I realize it is not in RFC form yet, but it is standards track. Editorial: - Abstract: The abstract should not contain citations. - 2, first paragraph: "This specification describes an (abstract) interface" Why is "abstract" in parentheses? - 3.1, definition of TFO, "allows to immediately hand over": I suggest either "allows <something> to immediately hand over" or "allows the immediate handover". -3.4: I agree with other comments that the UDP/UDP-lite draft should be included here. There may have been reason to separate them at one time, but since they are progressing together it no longer seems to make sense. While it may be inconvenient to recombine them at this point, keeping them separate just pushes that inconvenience off on the readers. -4: I find this section very hard to read due to the formatting of the primitive descriptions. Please consider either using complete sentences, or reformatting them into something that looks less like a blob of text.
Interesting piece of work. Thanks. I hope it will be maintained along the time Acknowledgement: "The views expressed are solely those of the author(s)." Really? Why this sentence?
Comments and nits: 1: Abstract. "The description results in a set of transport abstractions that can be exported in a TAPS API." What's a TAPS API? (please expand) 2: 3.1. Primitives Provided by TCP "Open: this is either active or passive" - "Open: This is either active or passive" (uppercase T)? 3: "Also optional, for multihomed hosts, the local IP address can be provided" This makes it sound ("Also optional") like the prior paragraph is optional. I don't think that that is intended -- perhaps (optional)? 4: "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis. more than TCP’s maximum segment size (minus options used in the SYN). " -- there is some broken fragment here. 5: "Send: this is the primitive that" - Uppercase 'T' ? Section 4.1. CONNECTION Related Primitives 6: "At least the Source Route option is mandatory for TCP to provide." -- perhaps for "TCP implementations to provide" 7: Section 5. Pass 3 This section is very helpful, but I was wondering if there might be a table published (not necessarily in the draft) which summarizes this info. E.g: | TCP | SCTCP | UDP | UDP-L | ----------------------------------------------+ Connect | X | X | X | X | Specify IP Options | X | | X | X |
Fully editorial comments: - First paragraph in intro: s/underlying TAPS system/underlying Transport Services (TAPS) system/ - This should not use normative language: "TCP implementations MUST NOT use TFO by default..." (see comment from EKR) - Also there is half a sentence missing in the same paragraph: "more than TCP's maximum segment size (minus options used in the SYN)." - s/Differentiated Services (diffuser)/Differentiated Services (diffserv)/ or s/Differentiated Services (diffuser)/Differentiated Services (DiffServ)/ - I (still) don't understand why draft-ietf-taps-transports-usage-udp was kept in a separate document, given there is even a separate empty section in this doc. You basically have to stop reading there, go to the other doc, read it, and come back. That doesn't make sense to me.
I have not yet completed my review of this document, but I note that it is targeted for Informative but also contains RFC2119 normative language, e.g., "TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis." If the intent is that this is to be Informational then this should be removed, and if it's to be BCP, then it needs to go back to IETF-LC for that