Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
draft-ietf-taps-transports-14

[Ballot comment]
Just a few very minor comments:

- 1, 2nd paragraph: Would it make sense to include citations for things like NewReno, TFRC, and LEDBAT?

- 3.5.1, 2nd to last paragraph: Would a citation to WebRTC (perhaps the overview or the transports draft)?

-3.5.2, paragraph starting with "For the following SCTP protocol extensions the BSD Sockets API..."
The paragraph is hard to parse.

[Ballot comment]

Thanks for a useful document. I think this will be quite
informative for many people so please consider my comments
below as just suggestions offered for consideration, and it's
entirely fine if you'd rather not even think about 'em. (I
can well imagine that a document like this could be polished
forever and never finished.)

- abstract: Having finished a first read of this I don't find
the "classifies" and "compares" claims from the abstract to
have really been met.

- end of p11 - seems like a truncated paragraph there or
something.

- 3.5 (and to a lesser extent 3.6): This reads to me as if
the authors regret that the world hasn't adopted the SCTP
(resp. DCCP) as "planned." There's no particular action
following from that, but we might want to consider whether or
not that's the impression we want readers to get. I think it
might be a tiny bit better to do a pass to try make the
language in those bits more neutral.

- 3.7: I agree with Alissa that referring to the TLS1.3 draft
would be good. SSL can also be referred to via RFC6101.  It'd
be a little better to refer to RFC7525 as BCP195 I think.

- 3.7.2: I think it'd be good to consider whether or not this
should describe the so-called 0RTT feature of TLS1.3.  That
is a dangerous implement that could be usefully covered in
this document as informing likely readers of this about how
to properly use (or more importantly, not use) that new
"feature" could be well worth while.

- 3.7.2: The mention of RNGs here is a bit odd. Those aren't
usually an external interface but rather a dependency that
the implementation has on the system/OS.  Similar things
didn't seem to be mentioned in other equivalent sections.
You also don't say that there's no standard API. There was
also a relatively recent paper on how awful TLS cert APIs are
and how those damage security that might be worth a
reference. [1] This section could maybe do with a little more
work. (If you want to, I'm nowhere near trying to insist.)

  [1]
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

- 3.9.1: Cookies as "MIME headers"? Huh? Was this text
checked over by some HTTP folks? That sentence makes me think
3.9 might need some more checking.

- 3.10.2: Seems odd to have URLs here for non-maintained
implementations of a rarely used protocol when the same
wasn't provided for very widely used protocols.

- 3.10 and 3.11: It wasn't clear to me why it's useful to
include these.

- 3.12: This seems oddly placed and I'm not clear why it's
worth including ICMP but not DNS or CDNs or load balancing or
issues related to head of line blocking.

[Ballot comment]
Thanks for writing this document. I found it to be very useful summary of the transport protocols.

* Section 3.1

Missing the Abort command.

* Section 3.3

Why does UDP has a reference to the base IPv6 spec [RFC2460]? Is this for the pseudo-header calculation? If so, it needs to be added to TCP as well.

* Section 3.3.1

- Might be worthwhile adding a reference to RFC6936 as well to explain the applicability of UDP zero checksums in IPv6. e.g.

OLD:
  IPv6 does not permit UDP datagrams with no checksum, although in certain cases this rule may
  be relaxed [RFC6935].

NEW:

  IPv6 does not permit UDP datagrams with no checksum, although in certain cases [RFC6936] this rule may
  be relaxed [RFC6935].

The following sentence at the end of Page 11 seems incomplete

Applications that need to provide fragmentation

* Section 3.12

The reference for ICMPv6 is wrong. It should be RFC4443 instead of RFC4433 as stated in the draft.

* Section 3.12.1

RFC1716 has long been obsoleted by RFC1812. Is there any reason to use the old router requirement spec?

* Section 5

ICMP can be used with multicast addresses as well.

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

IANA has reviewed draft-ietf-taps-transports-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA 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, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, "Aaron Falk" , spencerdawkins.ietf@gmail.com, taps@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Services provided by IETF transport protocols and congestion control mechanisms) to Informational RFC


The IESG has received a request from the Transport Services WG (taps) to
consider the following document:
- 'Services provided by IETF transport protocols and congestion control
  mechanisms'
  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 2016-09-09. 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, surveys, classifies and compares the
  protocol mechanisms provided by existing IETF protocols, as
  background for determining a common set of transport services.  It
  examines the Transmission Control Protocol (TCP), Multipath TCP, the
  Stream Control Transmission Protocol (SCTP), the User Datagram
  Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol
  (DCCP), the Internet Control Message Protocol (ICMP), the Realtime
  Transport Protocol (RTP), File Delivery over Unidirectional
  Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC),
  and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security
  (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol
  (HTTP), when HTTP is used as a pseudotransport.




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

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


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

Please note that this Last Call period has been extended to accommodate the end of August vacation season.

1. Summary

The document shepherd is Aaron Falk. The responsible Area Director is
Spencer Dawkins.

This document describes, surveys, classifies and compares the protocol
mechanisms provided by existing IETF protocols, as background for
determining a common set of transport services.  Protocols addressed
include TCP, SCTP, UDP, UDP-Lite, DCCP, ICMP, RTP, FLUTE/ALC, NORM,
TLS, DTLS, and HTTP when used as a pseudotransport.  It captures
important analysis needed for the TAPS working group goal of
developing an abstract API enabling applications to make use of modern
transports with the help of TAPS mechanisms, for example to probe and
verify end-to-end protocol transparency.  This is a useful first step
by the TAPS working group to proposing future abstractions and
mechanisms.

2. Review and Consensus

All the protocols referenced in this document are products of the
IETF.  The goal here is to introduce consisten terminology and pull
together a common view of a number of well-known protocols.  The
working group struggled early on in finding the right level of
abstraction but was able to achieve consensus on the approach
contained in the doc.  Each protocol section had one or two active
authors who are experts in their section and went through multiple
revisions.  The result is that about a dozen contributors have
provided text so the engagement was high, compared to the active
mailing list members.  A few objections have been raised about whether
the overall effort will be useful but the contents of this draft have
not been controversial.  The working group held a last call that
spanned an IETF meeting with a number of cleanup tasks identified.
Some new introductory text and restructuring on the doc was introduced
and a second, online last call, produced no comments.  It is the
opinion of the shepherd that the document is ready for publication.

3. Intellectual Property

This document introduces no new technologies beyond those already
published.

4. Other Points

There are no normative references, no IANA considerations.