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 an RTP payload format for ITU-T Recommendation G.711.0. The document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. Although G.711.0 is a lossless and stateless compression algorithm, it is a real compression algorithm and therefore results in variable bit rate encoding. In my view, this document is Ready with Issues. The issues that I am concerned about are described in the next two paragraphs. I am a novice in media encoding and the security issues raised by it. However, I was surprised to see that RFC 6562 (Guidelines for the Use of Variable Bit Rate Audio with Secure RTP) was not mentioned in the Security Considerations section. The VBR security problems cited in RFC 6562 seem to apply to this draft and the mitigation techniques described in the draft don't seem to properly address those problems. For example, adding statistically variable padding to very small G.711.0 frames would not prevent recognition of a prerecorded message if the set of all possible messages is known. If the authors of this draft have not consulted an expert on the security issues raised by VBR, they should do so. At least, I would expect to see a reference to RFC 6562 and an explanation of why the mitigation techniques described in the draft are adequate or a description of the circumstances where they fall short. In addition to this concern, a believe that there may be a buffer overrun vulnerability in the payload decoding algorithm described in section 4.2.3. The authors carefully ensure that the input buffer is not overrun but no similar protections for the output buffer are described. At least, I didn't see them. A buffer overrun of the output buffer would be a major flaw. If such a flaw is present (and I believe that it is), the document should not be allowed to proceed until this flaw is fixed. Here is a list of non-substantive issues that I noticed. On page 4, attribute A1 says: G.711.0 was designed as its primary use case for the compression of G.711 payloads that contained "speech" or other zero-mean acoustic signals. The grammar there is not correct. I would suggest instead: In the design of G.711.0, the primary use case was the compression of G.711 payloads that contained "speech" or other zero-mean acoustic signals. In section 4.1, you say that "one of the advantages of G.711.0 over G.711 with VAD is the lack of any VAD-inducing artifacts in the received signal." Do you really mean "VAD-inducing" or do you mean "VAD-induced"? On page 13, step H3 should start with "If this octet is 0x00", not just "If this octet 0x00". Otherwise, this introductory clause is missing a verb. On page 17, the last sentence of the description of complaw says "are used for". This should say "which are used for". On page 21, the second paragraph of section 6 includes the words "that not received". This should be "that are not received". In the first sentence of section 6.1, "payloads not received" should be "payloads are not received". Attachment: smime.p7s Description: S/MIME cryptographic signature