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

[Ballot comment]
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?

[Ballot comment]
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  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.

[Ballot comment]
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.

[Ballot comment]
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  |

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-taps-transports-usage-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-09-14):

From: The IESG
To: IETF-Announce
CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-taps-transports-usage@ietf.org, taps-chairs@ietf.org, Zaheduzzaman Sarker , taps@ietf.org, spencerdawkins.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (On the Usage of Transport Features Provided by IETF Transport Protocols) to Informational RFC


The IESG has received a request from the Transport Services WG (taps) to
consider the following document: - 'On the Usage of Transport Features
Provided by IETF Transport
  Protocols'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes how the transport protocols Transmission
  Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control
  Transmission Protocol (SCTP), User Datagram Protocol (UDP) and
  Lightweight User Datagram Protocol (UDP-Lite) expose services to
  applications and how an application can configure and use the
  features that make up these services.  It also discusses the service
  provided by the Low Extra Delay Background Transport (LEDBAT)
  congestion control mechanism.  The description results in a set of
  transport abstractions that can be exported in a TAPS API.  For UDP
  and UDP-Lite, the first step of the protocol analysis -- a discussion
  of relevant RFC text -- is documented in [FJ16].  XX RFC ED - PLEASE
  REPLACE [FJ16] WITH THE CORRECT RFC NUMBER XXX




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Zaheduzzaman Sarker. The responsible Area Director is Spencer Dawkins.

This document describes well established function calls as "primitives" that any program can use to get automated services from TCP, MP-TCP, SCTP, LEDBAT, UDP and UDP-lite protocol. This description gives very good information about the services provided by the protocols as in the RFC series. Further it describes the 3 pass process had been followed to derive the transport features. Over all this document serves as a useful source of information for using transport services.

2. Review and Consensus

As this describe primitives based on what already available in RFC series for those protocol it was straightforward to get consensus on the primitives. All versions of this document got a fair amount of discussions in the mailing list hence were well reviewed and got positive feedbacks on working group last call.

There were discussions on what protocols should the document cover, especially for inclusion of secure protocols such as TLS and DTLS. This was well communicated with respective workings. As at that time TAPS WG was lacking of security protocol expertise the consensus was to keep those out of the scope of the document.

Furthermore, for the shake of manageability the UDP and UDP-lite partitives were written in a separate document.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There is no normative downref and no IANA considerations.