The Use of AES-192 and AES-256 in Secure RTP
draft-ietf-avt-srtp-big-aes-06

3.1.  Usage Requirements

   When AES_192_CM is used for encryption, AES_192_CM SHOULD be used as

I think the 2nd AES_192_CM should be AES_192_CM_PRF

   the key derivation function, and AES_128_CM MUST NOT be used as the

s/AES_128_CM/AES_128_CM_PRF ?

   key derivation function.

   When AES_256_CM is used for encryption, AES_256_CM SHOULD be used as
   the key derivation function.  Both AES_128_CM and AES_192_CM MUST NOT
   be used as the key derivation function.

Same comments as above.

Please consider the nit and editorial comments from the Gen-ART Review
  by Richard Barnes on 10-Dec-2010:
  >
  > [Section3] In the first sentence, should "AES_CM PRF" be changed
  > to "AES_CM_PRF"?
  >
  > [Section3.1] Do you want to say explicitly that stronger KDFs MAY
  > be used?  That you could use the AES_256_CM KDF with AES_192_CM as
  > the bulk encryption algorithm, or use either 192 or 256 with 128?

#1) Support Russ' and Tim's discusses.

#2) Section 3: 

   In
   this note, the AES-192 counter mode PRF and AES-256 counter mode PRF
   are and are denoted as AES_192_CM_PRF and AES_256_CM_PRF
   respectively.

extra words "are and"?

#3) Section 3.1 (similar to Russ's 2nd comment): Should the rationale include a MUST?  For example:

   The cryptographic strength of the key derivation function MUST
   meet or exceed the cryptographic strength of the encryption method.

Please note Hilarie Orman's secdir review.

(1) In particular, she notes:

The block counter "b_c" is two octets, but the "default key lifetime"
is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
implementors introduce an internal counter to keep track of the
history of key usage (across sessions?)?  Perhaps earlier documents
explain this?

Should implementers use the rollover counter (ROC) from RFC 3711
in combination with b_c, or is there another mechanism that the
authors had in mind?

(2)  You might consider moving the rationale to the front of the section
as an alternative to Hilarie's suggestions on section 3.1,