A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-14

Thanks to Carlos for the opsdir review.

Nit: 
Page 6 - "Extension element types that dp not match the header extension format"
s/dp/do/

In general this is a well written document, but I have a small list of issues that you should consider fixing:

In Section 5:

   When SDP signaling is used for the RTP session, it is the presence of
   the 'extmap' attribute(s) that is diagnostic that this style of
   header extensions is used, not the magic number indicated above.

You lost me here. Which magic number do you mean here?


In Section 7:

   If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.

Why is this not a MUST?

   If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer.

As above.

In Section 9:

   In order to prevent DOS attacks, for
   example, by changing the header extension integrity protection SHOULD
   be used.

I can't parse this sentence.

OLD: The other major change is to update the requirement from the RTP
   specification and[RFC5285] 

NEW: The other major change is to update the requirement from the RTP
   specification [RFC5285]

   There are two variants of the extension: one-byte and two-byte
   headers.  Since it is expected that (a) the number of extensions in
   any given RTP session is small and (b) the extensions themselves are
   small, the one-byte header form is preferred and MUST be supported by
   all receivers.  A stream MUST contain only one-byte or two-byte

"or only two-byte" would be clearer.


   headers unless it is known that all recipients support mixing, either
   by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
   of-band knowledge.  Each RTP packet with an RTP header extension
   following this specification will indicate if it contains one or two
   byte header extensions through the use of the "defined by profile"
   field.  Extension element types that dp not match the header

do not match


   extension format, i.e. one- or two-byte, MUST NOT be used in that RTP
   packet.  Transmitters SHOULD NOT use the two-byte form when all
   extensions are small enough for the one-byte header form.
   Transmitters that intend to send the two-byte form SHOULD negotiate
   the use of IDs above 14 if they want to let the Receivers know that
   they intend to use two-byte form, for example if the RTP header
   extension is longer than 16 bytes.  A transmitter may be aware that
   an intermediary may add RTP header extensions in this case, the
   transmitter SHOULD use two-byte form.

I think you want '; in this case...." if this means what I think it
means.

   assignment of different IDs.  Any RTP header extension that do not

does not

   match this assumption MUST explicitly provide rules for what are


   cipher.  It can be noted that the default SRTP ciphers (AES CM 128
   bits with HMAC-SHA1) are relative weak and more modern ciphers are
   stronger and should be considered.

What's weak about AES-CTR-HMAC? I recognize that this was in the
secdir review, but I'm not sure what claim you are making here.