Ballot for draft-ietf-taps-transports
Yes
No Objection
Recuse
Note: This ballot was opened for revision 12 and is now closed.
In Sec 5, I wondered why only IPv4 was specified for the broadcast? "IPv4 broadcast (UDP, UDP-Lite, ICMP)"
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.
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.
In Section 3.7, it seems like a reference to draft-ietf-tls-tls13 is warranted.
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
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.
I'm a co-author.