Subject: [Taps] Stephen Farrell's Yes on draft-ietf-taps-transports-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 30 Nov 2016 14:40:13 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-taps-transports-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports/

----------------------------------------------------------------------
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.