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. _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
