On the Usage of Transport Features Provided by IETF Transport Protocols

Summary: Has enough positions to pass.

Spencer Dawkins Yes

Alexey Melnikov Yes

Comment (2017-09-13)
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.

Alia Atlas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2017-09-13)

- 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.


- 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.

Benoit Claise No Objection

Comment (2017-09-14)
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?

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2017-09-12)
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. 
                   | TCP | SCTCP | UDP | UDP-L |
Connect            |  X |    X   |  X  |   X   |
Specify IP Options |  X |        |  X  |   X   |

Mirja Kühlewind No Objection

Comment (2017-09-11)
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.

Terry Manderson No Objection

Kathleen Moriarty No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Alissa Cooper No Record

Eric Rescorla No Record

Comment (2017-09-11)
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