A General Mechanism for RTP Header Extensions
RFC 8285

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) Yes

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2017-06-19 for -12)
No email
send info
I like it. I did have a couple of non-blocking questions.

I couldn't parse this sentence.

  "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 

   In the one-byte header form of extensions, the 16-bit value required
   by the RTP specification for a header extension, labeled in the RTP
   specification as "defined by profile", MUST have the fixed bit
   pattern 0xBEDE (the first version of this specification was written
   on the feast day of the Venerable Bede).

is flipping awesome, but likely impenetrable for folks who haven't studied English history in the 600s and 700s. Perhaps a reference, or, more likely, just say "May 25" so it's not a mystery?

(Adam Roach) Yes

Comment (2017-06-20 for -12)
No email
send info
The use of the term "local" in this document is implicit and therefore confusing. Section 5 refers to "local identifier (ID)", while section 7 refers to "Local identifiers". Neither indicates what the identifiers are local to, and some implementors have chosen to interpret this as meaning "local to the sender machine." See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=1361206

I believe the intention here is for "local" to mean "local to this session." This meaning should be made explicit. And, for avoidance of doubt, the document should clarify that the negotiated identifiers use the same numeric value in both directions. This is implied by much of the text, but it never stated outright. Because so many other session attributes (e.g., payload types) can be negotiated to be different in each direction, many implementors are likely to assume the same applies here. As the above bug demonstrates, this leads to real interop issues in the field.

Nits:

   element (no alignment is needed), and parsing stops at the earlier of
   the end of the entire header extension, or in one-byte headers only
   case, on encountering an identifier with the reserved value of 15.

Put quotation marks around "one byte headers only".
____

   Each extension element MUST starts with a byte containing an ID and a
   length:

s/starts/start/
____

The attribute definition in section 6 says "Value:" instead of "Value: none."  -- Fix or refer to the IANA section instead.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2017-06-22 for -12)
No email
send info
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]

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-06-19 for -12)
No email
send info
Thanks to Carlos for the opsdir review.

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

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2017-06-20 for -12)
No email
send info
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.

(Kathleen Moriarty) No Objection

(Eric Rescorla) (was Discuss) No Objection

Comment (2017-06-19 for -12)
No email
send info
   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.

Alvaro Retana No Objection