I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a file format for storing and transporting flow data. Typically the flow data will be collecting in the IPFIX format, although it is of course potentially possibly to convert other flow data to use this format; section 6 discusses such a case. I urge the IESG to get specific additional review from the law enforcement/security investigation community surrounding the handling of evidence in an ongoing investigation prior to approving this draft. Section 4 cites that use case as a significant motivation. However, I'm concerned that the requirements in section 5 and thus the resulting protocol are inadequate to that community's needs. Section 3 talks about advantages of the file format including that files can be concatenated or split on message boundaries. There is no file header or trailer. However there are records such as those described in 8.1.3 that describe metadata for the file. Particularly in investigation environments it seems problematic to get into a situation where the file has metadata that claims inaccurately to describe the file especially when this happens using mechanisms explicitly supported by the file format and the situation cannot be detected. In the document use case I think you want a mechanism to confirm that a file has not been added to or removed from. Section 7.3.4 requires using the file write time as the export time. That seems potentially problematic in an investigation. TPerhaps the message details option in 8.1.4 is supposed to handle this; if so, text explaining how this works should be added to 7.3.4. The handling of authentication seems problematic. The text points out that TLS can be used to provide transient authentication from the exporter to collector. Discussion of the lack of data origin authentication (authentication that can be verified after the fact by a third party) needs to be added to the security considerations section; this seems important for the 7.3.4 use case. I'm not asking for digital signatures to be added at the exporter, simply for discussion of the consequences on having hop-by-hop authentication. However there is a more serious lack on the authentication front. There is no way for a file writer to describe the authenticated identity of the exporter. I'd expect 8.1.3 and 8.1.4 to include attributes to describe the TLS identity of the exporter. The template in 8.1.1 uses md5. There's insufficient documentation for me to tell whether the cryptographic properties, particularly collision resistance, are important to this use of md5. My guess is that they are and thus md5 may not be the best hash to use. Is a per-message checksum really the right granularity? The security considerations section is very weak.