I 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.   The document describes how IPFIX (IP Flow Information Export) operates in the context of IPFIX “mediators.” In the IPFIX context, a mediator is an entity that processes data received from an “exporter” (e.g., a router), before passing the data to a consuming entity (e.g., a network management system), in theb IPFIX format. A mediator can perform various types of processing on IPFIX data, e.g., aggregation, correlation, and anonymizing, in addition to format conversion.   The security considerations section in this document is brief, just three paragraphs. It cites the corresponding sections of RFC 7011 (the base IPFIX specification) and RFC 5655 (the IPFIX file specification). It also addresses two considerations that the authors view as specific to the mediator context. Specifically, the authors note that a mediator is an MITM, and thus the confidentiality and integrity of the IP flow data that traverses a mediator can be affected. The authors note although one can use certificates to identify upstream source of processing entities (supported by data elements defined in RFC 5655), this does not provide secure, end-to-end assertions about the upstream entities.   Both of these considerations are accurate an well-described here. I briefly examined the security considerations sections of the cited RFCs. I was impressed by the scope of the security discussion in RFC 7011; it mandates support for TLS (v1.1 or later) and DTLS, and calls for (SHOULD) use of certificates in support of mutual authentication of IPFIX entities. There is even a DoS discussion. Good job! The security considerations section of RFC 5655 is shorter, but also appropriate for its context. 5655 calls for (SHOULD) use of CMS (vs. TLS and DTLS) for IPFIX files. It also examines additional security issues relevant to the files. (I have one minor quibble with the text here; it refers to using TLS to “sign” data, which is not correct. The integrity and authentication mechanisms offered by TLS do not include signatures.) Citing the security considerations sections of these other RFcs was appropriate.   I wish more I-Ds did as good a job as this one (and its predecessor RFCs) with respect to security considerations sections.