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 describes a new RTP payload format, extending existing RTP capabilities. Based on my limited understanding of RTP, this introduces no new security considerations. The security considerations section starts off by saying this, but then goes on to talk about various security properties that could be added by various means. I found the text to be a little confusing, especially when it makes recommendations without detailing any particular threats. I would suggest simplifying the security considerations. Here is the current text: "RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [6], and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this document are confidentiality, integrity and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets through suitable cryptographic integrity protection mechanism. Cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection and at least source authentication capable of determining if an RTP packet is from a member of the RTP session or not. Note that the appropriate mechanism to provide security to RTP and payloads following this document may vary. It is dependent on the application, the transport, and the signalling protocol employed. Therefore a single mechanism is not sufficient. Usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED, for example by use of the Secure Real-time Transport Protocol (SRTP) [12]. Other mechanisms that may be used are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over TCP), but other alternatives may exist. Refer also to section 9 of RFC YYYY [3], as no reasons for separate considerations are introduced in this document." I would suggest the following simplified text: "RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [6], and in any applicable RTP profile. No additional security considerations are introduced by this specification." (or something like this). --Scott