RTP Payload Format for the Opus Speech and Audio Codec
draft-ietf-payload-rtp-opus-11

I agree with Barry that Section 3 should be explicitly called out as an applicability statement.

Thank you for adjusting the text in the security considerations section to encourage the use of strong security mechanisms.

Meta-comment - it looks like the notification field is pointing only to Ali. If that's intentional, rock on, but I've had some accidentally-minimal notification lists on drafts recently, and wanted to mention that.

This draft seemed very clear to me, one not skilled in the art. Thank you for that. 

I have a few comments. If you have questions, please ask, but they're non-blocking (so do the right thing).

In this text:

3.  Opus Codec

   Further, Opus allows transmitting stereo signals.
   
I wasn't sure what this was telling me until I got to section 3.4, and saw this text: "signaled in-band in the Opus payload". Perhaps adding that phrase in Section 3 would be helpful?

In this text:

3.1.2.  Variable versus Constant Bitrate

   One
   reason for choosing CBR is the potential information leak that
   _might_ occur when encrypting the compressed stream.  See [RFC6562]
   for guidelines on when VBR is appropriate for encrypted audio
   communications.
   
I THINK I know what "potential information leak" means in this case, but I'm guessing. I learned a lot from the [RFC6562] reference. Is it possible to provide a short clue here? Would it be correct to say something like "One reason for choosing CBR is that some codecs have been observed to provide predictable VBR patterns for highly structured dialogs where only a few phrases are expected, and potentially leaking information without requiring an eavesdropper to decrypt the payload"?

Also in 3.1.2:

   The bitrate can be adjusted at any point in time.  To avoid
   congestion, the average bitrate SHOULD NOT exceed the available
   network bandwidth.  
   
I'm kind of wondering how you intend for the sender to know what the "available network bandwidth" is. I notice a reference in Section 3.3 to 

   (2) an externally-provided estimate of the
   channel's capacity; 
   
Is "the available network bandwidth" this externally provided estimate? What should a sender be looking at, to fulfill this SHOULD NOT?

Of course, I'm wondering why this is SHOULD NOT, instead of MUST NOT. Is this recognizing that available network bandwidth can change instantaneously (so a careful sender might still find itself sending too fast for a short period of time), or is there something else going on?

As long as I'm mentioning section 3.3, if the "externally-provided estimate" had some reference, that would be helpful (unless, of course, this is obvious to those skilled in the art). The term only appears twice in 3.3, with no pointers.

In this text:

5.  Congestion Control

   It is RECOMMENDED that senders of Opus encoded data apply congestion
   control.
   
Is there a particular mechanism you're thinking of here? If you could make that clearer, even just providing a reference, that would be helpful for me as a reader.

In other news, I support Kathleen's Discuss on SHOULD SRTP, and if it becomes a SHOULD and not a MUST, I'd suggest adding a sentence or two explaining why not using SRTP is the right thing to do.

- 3.1.2: s/_might_ occur/occurs/ the information leak does
occur unquestionably, the only uncertainty is whether or not
someone cares about that, whereas the current text implies
that the leak might not be real. As written, the text is
misleading, though not sufficiently to make this a DISCUSS.
(I am assuming there is no result that shows that encrypted
OPUS traffic is somehow not leaking information in the way
other codecs do.)

- 6.1, maxptime and ptime: I read this as saying that 3, 6,
9 etc are all valid values, but that e.g. 43 is not. Is that
correct? In other words can I mix frames that contain
different durations of audio into one RTP packet? (You may
have told me earlier, but I've forgotten already, sorry:-)