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.