Skip to main content

On the Usage of Transport Features Provided by IETF Transport Protocols
draft-ietf-taps-transports-usage-09

Yes

(Spencer Dawkins)

No Objection

(Adam Roach)
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Kathleen Moriarty)
(Suresh Krishnan)
(Terry Manderson)

No Record


Note: This ballot was opened for revision 08 and is now closed.

Warren Kumari
No Objection
Comment (2017-09-12 for -08) Unknown
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   |
Alexey Melnikov Former IESG member
Yes
Yes (2017-09-13 for -08) Unknown
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.
Spencer Dawkins Former IESG member
Yes
Yes (for -08) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2017-09-13 for -08) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (2017-09-14 for -08) Unknown
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?
Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-09-11 for -08) Unknown
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.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Eric Rescorla Former IESG member
No Record
No Record (2017-09-11 for -08) Unknown
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