Ballot for draft-ietf-avtcore-rfc5285-bis
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Thanks to Carlos for the opsdir review. Nit: Page 6 - "Extension element types that dp not match the header extension format" s/dp/do/
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.
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?
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.
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.