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 document defines new RTP payload format for sending forward error correction that is generated by the 1-D interleaved parity code. The security considerations section refers to the generic RTP (RFC3550) security considerations. It also mentions generic solutions to different security problems (encryption for confidentiality, integrity protection mechanism for integrity and authentication of the source of the payload). It does not list any specific mechanisms, but points to Secure Real-time Transport Protocol SRTP (RFC3711), IPsec (RFC4301) and TLS (RFC5246). The only thing missing from the security considerations section is that it should mention that the repair flow should require exactly same security features that what is provided to the source flow. The repair flow packets are xor of the multiple source flow packets, and if those do not get exactly same confidentiality, integrity and authentication of source protection then the original source flow confidentiality, integrity or authentication of the source could be compromized. I.e. it is not acceptable for using for example AES, SHA2-256 to protect source flow, but send repair flow without encryption and without integrity protection, as when doing that attacker can replace repair flow packets, and cause source flow packets to drop triggering error correcting procedures on the receiver which will then use repair flow packets having weaker security than source flow packets. -- kivinen at iki.fi