Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
RFC 8095

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

(Alia Atlas) Yes

Comment (2016-11-30 for -12)
No email
send info
In Sec 5, I wondered why only IPv4 was specified for the broadcast?  
"IPv4 broadcast (UDP, UDP-Lite, ICMP)"

Ben Campbell Yes

Comment (2016-11-30 for -12)
No email
send info
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.

Spencer Dawkins Yes

(Stephen Farrell) Yes

Comment (2016-11-30 for -12)
No email
send info
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.

(Jari Arkko) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2016-11-30 for -12)
No email
send info
In Section 3.7, it seems like a reference to draft-ietf-tls-tls13 is warranted.

Suresh Krishnan No Objection

Comment (2016-11-29 for -12)
No email
send info
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.

Terry Manderson No Objection

(Kathleen Moriarty) No Objection

Comment (2016-11-30 for -12)
No email
send info
Thanks for adding in TLS to the replay protection list in section 5 from the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06774.html

Alvaro Retana No Objection

Mirja Kühlewind (was Abstain) Recuse

Comment (2016-11-22 for -12)
No email
send info
I'm a co-author.