Reviewer: Tatuya Jinmei Review result: Ready I've reviewed version 13 of draft-ietf-ipsecme-iptfs. I'm by no means an IPsec expert or very much familiar with ESP details, so it's quite possible I may miss something in its technical details. That said, I think it's very well written to understand the concept, and I've not found any obvious problems. So I'd say it's "ready". It looks like one underlying high level question is whether we should rather standardize a (single, unified) mechanism that does not necessarily depend on ESP. For that question, I think this response from the author is convincing: > We designed the encapsulation with IPsec/IP-TFS (IP traffic flow > security) in mind. This work defines sending fixed-sized packets at > a constant rate specifically decoupled from the user load to achieve > a high degree of traffic flow security. We might design a generic tunneling mechanism that parameterizes the sending rate or whether to use of padding or encryption, but unless we have a clear demand for such a mechanism today (which I actually don't know well but doesn't look likely) that seems to me to be over generalization. I have a couple of very minor comments on the draft content: - In Section 6, some integer fields are explicitly defined as "unsigned" while some others don't specify the sign. Maybe it's obvious (all seem to be unsigned anyway), but for consistency and by convention I'd suggest clarifying the sign for all integer fields. - Since the "BlockOffset" field is 16-bit, this mechanism can't support IPv6 jumbograms. I don't really think it a problem, and it may not even be worth mentioning, but I'm pointing it out just in case the author wants to clarify it. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
